home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.19971216-19980424
/
000035_news@newsmaster….columbia.edu _Fri Jan 2 14:24:28 1998.msg
< prev
next >
Wrap
Internet Message Format
|
1998-04-22
|
8KB
Return-Path: <news@newsmaster.cc.columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id OAA20806
for <kermit.misc@watsun.cc.columbia.edu>; Fri, 2 Jan 1998 14:24:28 -0500 (EST)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id OAA28806
for kermit.misc@watsun; Fri, 2 Jan 1998 14:24:27 -0500 (EST)
Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Trying to speed up file transfer
Date: 2 Jan 1998 19:24:26 GMT
Organization: Columbia University
Lines: 151
Message-ID: <68jeta$nmp$1@apakabar.cc.columbia.edu>
References: <19980102181301.NAA19057@ladder02.news.aol.com>
NNTP-Posting-Host: watsun.cc.columbia.edu
Xref: news.columbia.edu comp.protocols.kermit.misc:8201
In article <19980102181301.NAA19057@ladder02.news.aol.com>,
Poole22 <poole22@aol.com> wrote:
: Find below the kermit script I'm using and the statistics/status output of
: the kermit session. I am negotiating with the remote host kermit
: administrators to run a CAUTIOUS kermit command rather than leave their
: kermit settings as default. They supply many financial institutions with
: data but say kermit is slow and do not encourage its use (I am debating this
: point with them!).
:
Thank you. Most people, quite understandably, do not understand the tradeoff
between speed and robustness, and expect file transfers to be both blindingly
fast and totally robust out of the box, which, unfortunately, does not often
jibe with conditions in the real world.
: When receiving data I though I could set the receive
: packet size on the local host without any changes on the remote host. This
: example below didn't seem to work since it sent the same number of packets
: (520) and actually took longer. 520*1000 bytes is more than 10 times the
: file size of 40139 bytes.
:
: KERMIT SCRIPT
: ...
: ;------------------------------------------------------
: ; KERMIT GENERAL SETUP
: ;------------------------------------------------------
: set modem type usrobotics ; modem type, e.g. US ROBOTICS
:
I infer from this that you are using C-Kermit 6.0 on the local end. Therefore
you should also be getting RTS/CTS (hardware) flow control automatically by
virtue of the "set modem type" command.
: set speed 38400 ; modem speed, e.g. 9600 bits per sec
: set line /dev/tty1 ; serial line device name
: set dial method tone ; TONE phone (as opposed to PULSE)
: set parity none ; no parity, 8th bit is ignored
: set delay 30 ; time allowed to switch from server/client
:
That will make anybody think Kermit is slow! But since this script is for
the local Kermit (the one making the call), you don't need this command anyway,
since it only affects the remote one (on the computer you are calling).
: set dial timeout 30 ; time allowed for modem connection
: set handshake none ; no handshaking (xon causes failure)
: set flow auto ; Automatic choice of flow control
:
This command only affects the *next* set "set line" or "set host" command.
But anyway, it's the default, so no harm done.
: set file type text ; all files transferred are of type TEXT
: set exit warning off ; stop requirment for stdin when exiting
:
If you are getting "Connection still open" warnings on exit, it usually
indicates indicates improper setup or connection of the modem.
: set receive packet 1000 ; pack size from receviced files only
: set window 4 ; Not currently set at the ISMA end.
:
Did you know that if the remote Kermit is in server mode, you can set its
parameters from the client:
remote set receive packet-length 1000
remote set window 4
Of course, this depends on which Kermit program and version they are running
on their end. Nothing too ancient, I hope.
: (...dial & login script omitted...)
: show protocol ; for information only
: input 10 RUFAS>
: if fail error (006) No RUFAS prompt
:
I wonder what RUFAS is.
: output RECEIVE PRITST\13 ; remote VMS/RUFAS command
: receive ./kisma.48317.dat ; local Unix kermit command
:
If RUFAS supports server mode, that would be a more straightforward way
of using it. Put it in server mode, and then send files to it, get files
from it, send it commands, etc.
By the way, do you *have* to tell it the filename? I ask because this might
give a clue as to its (RUFAS's) identity.
: KERMIT CONNECTION OUTPUT
:
: kermit> ISMA02 - Vax 4000-400
: kermit>
: kermit> Username: RMT124
: kermit> Password: >>RUFAS>
:
Aha, so RUFAS is someting on VMS... So is it C-Kermit? (Which version?)
Or is it Kermit-32, which hasn't been supported since 10 years ago?
: kermit> A>201, RECEIVE PRITST COMPLETED
: kermit> RUFAS>Executing /home/gpo/.kermrc for UNIX...
: kermit> Dial directory is /home/gpo/.kdd
: kermit> Executing /home/gpo/.mykermrc...
:
What are these messages from UNIX C-Kermit? It looks to me as if you have
somehow gotten it to run your script *before* it executed your initialization
and customization files. Is that what you wanted?
The STATISTICS command on the local end says:
:
: kermit> files transferred : 1
: kermit> packets sent : 520
: kermit> control characters : 902 prefixed, 0 unprefixed
: kermit> window slots used : 1 of 4
: kermit> packet length : 80 (send), 1000 (receive)
: kermit> compression : yes [~] (5212)
: kermit> block check type used : 3
: kermit> elapsed time : 87 sec
: kermit> transmission rate : 38400 bps
: kermit> effective data rate : 461 cps
:
Hence your (and the remote host Kermit administrators') complaint that
"Kermit is slow".
: 520*1000 bytes is more than 10 times the file size of 40139 bytes.
:
Yes, but as you can see the remote Kermit gave C-Kermit permission for a
maximum packet length of 80 bytes and a window size of 1. The file receiver
controls the packet length, and the window size must be agreed upon by both
parties. The remote Kermit demanded, and got, the bare minimum, and quite
predictably, throughput stank.
Diagnosis:
Either (a) the remote Kermit program lacks any of the "modern" (i.e. circa
1985) performance features of the Kermit protocol, or (b) the remote site
administrators are selecting them.
Cure:
The remote site administrators should install an up-to-date Kermit version
and configure it to allow fast transfers, to the extent their host and
communications equipment can tolerate them. Kermit can go just as fast, and
usually faster, as any other protocol on the same connection, and still have
better error recovery characteristics (e.g. sliding windows with selective
retransmission).
More information:
http://www.columbia.edu/kermit/ The Kermit Project website
http://www.columbia.edu/kermit/faq.html The Kermit FAQ (see item 4)
http://www.columbia.edu/kermit/perf.html File-transfer benchmarks
http://www.columbia.edu/kermit/ck60.html C-Kermit 6.0 for VMS (etc)
"Using C-Kermit", 2nd Edition See the chapter on peformance
- Frank